Encrypted communications systems are well known. Many of these systems provide secure communications between two or more users by sharing one piece of information between the users, which permits only those users knowing the shared information to properly decrypt a message. The shared information is known as an encryption key variable, or key for short. Loading this key into an encryption device in a communications unit is a basic requirement that allows secure communications to occur. To retain security over a long period of time, the keys are changed periodically, typically weekly or monthly.
Loading new keys, called rekeying, can be done in various ways. Over-the-air rekeying is achieved by transmitting the keys from a central site to communications units over a typical secure channel. Manual rekeying is accomplished by connecting a cable from a hand-held device (also called a key variable loader, or keyloader for short) to the communications unit and downloading the keys from the keyloader into the communications unit. Over-the-air rekeying takes a few seconds, and the process involved in manual rekeying, including locating the unit, connecting the loader, etc., takes much longer.
Thus, the use of over-the-air rekeying is a big timesaver and a security improvement when rekeying a large communications system. As systems grow larger, with thousands of communications units in one system, the need for multiple keys becomes evident. In secure RF trunked systems, such as the communications system described in U.S. Pat. No. 4,882,751, it is often likely that different groups within a large system require their own key or keys, possibly to increase internal security or to minimize the number of times it is necessary to reload keys over a period of time.
In a situation where IPsec is also implemented, over-the-air rekeying must work alongside with IPsec. As is known, IPsec is defined in RFC 4301 and is recognized by the industry as an application to encrypt and/or authenticate data traffic at the IP level. There are two general methods for IPsec key management: manual key and derived key. Manual key involves the use of static symmetric keys in communications units at both a source and destination. Derived key involves having both endpoints generate a common session key, e.g. using a Diffe-Helman exchange, followed by the mutual authentication of both endpoints. The methods for derived key management are defined under the public Internet Key Exchange (IKE) (as defined in RFC 4306) guidelines. The IKE exchange for key derivation and mutual authentication consists of several messages. Due to performance issues, it is undesirable to conduct an IKE exchange in certain communications systems, e.g. in a communications system adhering to APCO Project 25 (Project 25 for short).
For Project 25, key management is preferably performed using static symmetric keys and sending the static symmetric keys over the air. Such key management is specified in TIA102.AACA and TIA102.AACB and is termed over-the-air-rekeying (OTAR). Using OTAR has a number of advantages. For example, OTAR allows for defining crypto periods where new key material is used. OTAR also identifies the use of indices, or keysets, to enable a communications unit the flexibility of using keys for either an old crypto period or a new crypto period. Using keysets enables the communications units to maintain continuous communication through a crypto period changeover, even if the communications units are not all synchronized to the same crypto period. IPsec manual key management does not provide these benefits, e.g. allowing for continuous operation through crypto period changeovers (i.e. using keysets). Nor does IPsec define interoperation with Project 25 OTAR key management.
Accordingly, there exists a need for a new method and apparatus for encrypted communications using IPsec keys.
Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions and/or relative positioning of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of various embodiments of the present invention. Also, common but well-understood elements that are useful or necessary in a commercially feasible embodiment are often not depicted in order to facilitate a less obstructed view of these various embodiments of the present invention. It will further be appreciated that certain actions and/or steps may be described or depicted in a particular order of occurrence while those skilled in the art will understand that such specificity with respect to sequence is not actually required. It will also be understood that the terms and expressions used herein have the ordinary meaning as is accorded to such terms and expressions with respect to their corresponding respective areas of inquiry and study except where specific meanings have otherwise been set forth herein.